NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/564

Text File | 1996-08-05 | 7.0 KB | 175 lines

Path: cs.uwa.edu.au!jasonb
From: [e-mail] (Jason S Birch)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: PPC compilers
Date: 9 Jan 96 08:23:44 GMT
Organization: The University of Western Australia
Message-ID: <[e-mail]>
References: <[e-mail]> <4b77tq$[e-mail]> <MQAQx*[e-mail]> <4bqhnf$[e-mail]> <[e-mail]> <4c9i2l$[e-mail]> <4cf0ep$233@ra.i   <4ck47h$[e-mail]> <[e-mail]> <4com6v$[e-mail]> <[e-mail]> <4crfb9$[e-mail]>
NNTP-Posting-Host: decadence.cs.uwa.oz.au
X-Newsreader: NN version 6.5.0 #3 (NOV)

[e-mail] (Stephan Schaem) writes:
>Jason S Birch ([e-mail]) wrote:
>: Again: *If* he's trying to create a data type with certain
>: implementation-dependent size-requirements (such as in the bltcon0
>: case, assuming no headers to give us one) *then*, at that point in
>: time, he has to know the size of the type in order to define it
>: correctly. He stated that earlier - check what I've underlined.

> He said he would create a structure... not a new type.

You're saying a new structure *isn't* a new type?

> Now, tell me how he can forget that chipregs->bltcon0 is
> of type UWORD when he will declar *b and use *b (I guess you
> could forget what type are your variable, but personaly think its
> not to wise)

typedef uword bltcon0_t;
...
struct chipregs_t {
    ...
    bltcon0_t    bltcon0;
    ...
};

struct chipregs_t    chipregs;
bltcon0_t            *b;

Now he can safely use *b wherever a bltcon0_t is required, and given
sufficient support functions, never needs to know that it's a uword -
all he has to keep in mind are what values a bltcon0_t is allowed to
take.

> I'm sorry again , I dont see how you can program not knowing
> the type of your variable when you use them? Is it a pointer to a
> string C string? a pointer to a P String?

Again, you're misunderstanding. If you have a type blah, and a
function takes a variable of type blah *, then by all means create a
variable of type blah (or blah *) and pass it's address (or the
variable itself) to the function. You do *not*, however, need to know
if blah is really, say, a 32-bit integer. With assembler, you do.

> Should I mask the variable
> before I shift? etc...

If you use bitfields, you don't even have to care about masking and
shifting:

typedef struct {
  int foo : 2;
  int bar : 4;
  int bob : 10;
} fred_t;

main()
{
    fred_t fred;

    fred.foo = 3;
    fred.bar = 7;
    fred.bob = 11;

    return 0;
}

Produces:
__code:
main:
              MOVE.L         A7,D0                    ;200f
              SUBQ.L         #$4,D0                   ;5980
              CMP.L          __base(A4),D0            ;b0ac 0000
              BCS.W          _XCOVF                   ;6500 0000
              SUBQ.W         #$4,A7                   ;594f
___main__1:
              MOVEQ.L        #$3,D0                   ;7003
              BFINS          D0,$2(A7){0:2}           ;efef 0002 0002
              MOVEQ.L        #$7,D0                   ;7007
              BFINS          D0,$2(A7){2:4}           ;efef 0084 0002
              MOVEQ.L        #$b,D0                   ;700b
              BFINS          D0,$2(A7){6:10}          ;efef 018a 0002
              MOVEQ.L        #$0,D0                   ;7000
___main__2:
___main__3:
              ADDQ.W         #$4,A7                   ;584f
              RTS                                     ;4e75

fred_t can be your interface to some custom chip; foo, bar, and bob
can be "registers" you can use for whatever is required. The
definitions tell you exactly how many bits each can take, and that's
all you need to know. The compiler will take care of the rest.

>: However, once done, he can then safely create variables of that type
>: (the abstract one he's defined, which happens to be the right size) and
>: safely assign appropriate values to them, without having to worry if
>: the eventual assignments are implemented as a .c, .w, or .l. He can

> He defined a structure not a type... read what you underlined.

Structures *are* types.

> move.type    (a0),(a1) ... so what if type read .word or .chipreg

The "so what" is that you *need* to know if it really is a type .word,
or .byte, and can't simply use it as type .chipreg. Oh, and you have
to repeatedly say .word (or whatever) almost every time you use it.

> In asm you are forced to write what your thinking in all its detail,
> this mean forced to know your variable type. Something you should do
> even in C.

Not if you want portable code, you shouldn't, and with sufficient
support functions, you needn't.

>: The question is not about whether you need to know if a variable is a
>: float or a long, since they are "abstract" types (and can be different
>: sizes on different machines). The question is whether you need to know
>: how many bits are in each, and what each bit means. In assembler, you
>: do need to know the former, and occasionally the latter.

> When you program in C... on what basis do you select your variable type?
> Do you limit yourself to int/float? for all integer work you use int,
> and real you use float?

Of course not. If I need a lot of precision, I use double. If I prefer
speed and it doesn't need to be so accurate, I use float. If it
doesn't need to be floating point at all, I'll use an ordinal type. If
I don't want to have to care how big it's going to be on a particular
implementation, I'll go with long or perhaps "natural", where natural
can be typedef'd appropriately when sizeof(word) and sizeof(long) are
known. You are quite welcome, as I've said, to use the knowledge that
ANSI guarantees. If you want to be safe, however, you should not use
information that your particular implementation defines.

> In C or asm I choose type according the the min range they hold.
> I cant imagine choosing a type for my operation without knowing the
> type range.

You can't know the type range beforehand for any possible
implementation. C does not guarantee it. You can use sizeof at compile
time, however.

>: > ANSI define very well the minimum size of its type.

>: It does *not* define that ushort is the same as two bytes, which is
>: what you are claiming above as being equivalent. It only guarantees
>: that char <= short <= long.

> It define that ushort can hold value from 0 to 65535... this is what I
> claim. ANSI C do define min range for the basic types, it would be
> unthinkable otherwise.

It does *not* define that ushort can hold values from 0 to 65535.
Check it. There are machines with other than multiples of 8 bit word
sizes, you know.

> Stephan

--
Jason S Birch                        ,-_|\ email: [e-mail]
Department of Computer Science      /     \ Tel (work): [phone]
The University of Western Australia *_.-._/ Fax (work): [phone]
Nedlands  W. Australia  6907             v  Tel (home): [phone]